🐘 The Case of the Pink Elephant

Why Lock Screen Policies Didn’t Apply on Newly Built Windows 11 PCs

When building a room full of brand‑new Windows 11 PCs, you expect consistency. Same hardware. Same build process. Same policies. Same results.

So when one machine in a group of ten suddenly decides to display a random desert or waves lock screen instead of the expected corporate QR code, it stands out like a pink elephant.

This post walks through a real-world investigation and explains why the lock screen configuration failed to apply correctly how to diagnose and avoid this kind of issue in the future.

The Symptoms

During setup of ten newly built Windows 11 24H2 PCs in a training room, we noticed inconsistent lock screen behavior:

• Most systems showed a generic blue Windows background
• One system correctly displayed the similarly blue company-customized image
• One system,(our Pink Elephant) showed a random Windows Spotlight-style image of the desert

All systems were built using the same process and configured using the same account, making the inconsistency difficult to explain at first glance.

First-Level Checks: Intune Policy Status

The initial investigation started in Intune, reviewing the Device Configuration blade to see whether the lock screen policies had applied.

![[PinkElephant1.png]]

• The lock screen configuration profile was targeted correctly
• Some settings showed as failed

Digging deeper into the specific policy revealed exactly which setting failed, but not why.

The Real Clues: MDM Event Logs

To go beyond Intune’s surface-level reporting, the next step was reviewing the local MDM diagnostics logs on the affected PC.

We took a look at the DeviceManagement-Enterprise-Diagnostics event log which lives here:

Applications and Services Logs  
└─ Microsoft  
   └─ Windows  
      └─ DeviceManagement-Enterprise-Diagnostics  
         └─ Admin

This log contains detailed messages about MDM policy processing, including errors when specific settings fail to apply. In this case, the logs showed the lock screen personalization settings failing during application.

![[PinkElephant2.png]]

If physical access or remote access isn’t available, you can use the Collect Diagnostics option in Intune can be used to gather the same logs remotely, packaged into a downloadable ZIP. The log collection contains a LOT of information, but for our purposes today we're looking for the DeviceManagement-Enterprise-Diagnostics log. In the downloaded zip you're looking for a directory like (77) FoldersFiles temp_MDMDiagnostics_mdmlogs-2026-03-26-20-04-42_cab obviously the date will be different.

Inside that directory is a cab file that you've got to extract, and it contains (among many other things) microsoft-windows-devicemanagement-enterprise-diagnostics-provider-admin.evtx which is an extract of that event log.

The Root Cause: Windows Pro vs Enterprise

The key insight came from another error message that was found in the event log.

![[PinkElephant3.png]]

Licensing? Why would a fully licensed PC not be able to apply the setting?

The reason here is that some settings are only supported on specific versions of Windows, so if the device is Windows Professional it won't support some settings that are only supported on Enterprise.

For this case specifically, here’s what was happening:

• Devices ship from the vendor with Windows 11 Pro
• When a user with an M365 E5 license signs in, Windows is automatically uplifted to Enterprise
• That uplift is not instantaneous and often requires a reboot

Certain Personalization CSP settings—such as:

• Lock screen background
• Disabling lock screen tips

…are only fully supported on Windows Enterprise (or Pro with special conditions).

Because the affected device was still running Windows Pro when Intune attempted to apply those settings, the policies failed. Once they failed, Windows reverted to its default behavior—displaying a random lock screen image.

To further muddy the waters, the PC was set up with by an IT Admin using a separate account they use for elevated privileges. I'll let you guess whether or not that account had an M365 license that contains a Windows Enterprise license.

(It didn't.)

“But the Docs Say Pro Is Supported…”

Microsoft documentation does say that the Personalization CSP can work on Windows Pro:

![[PinkElephant4.png]]

However, the beginning of the doc starts with this blurb:

![[PinkElephant5.png]]

So essentially its only supported when

• SetEduPolicies is configured via SharedPC CSP, or
• The device is in Shared PC mode with the BootToCloudPCEnahanced policy applied.

Without meeting those conditions the personalization settings are effectively Enterprise-only.

Why Only One PC Worked

In our case, the working PC was repurposed and did not actually follow the same build process as the others, it was upgraded form Windows 10 to 11 and then set up for the room.

Key Takeaways

If you’re deploying or troubleshooting policies via Intune, keep these lessons in mind:

1. OS edition matters - Personalization CSP settings (as well as many others!) are only supported on Enterprise
2. Intune alone might not be enough - Always check MDM event logs for real error context
3. Reboots matter - Especially during license uplift scenarios

Final Thought

This issue wasn’t caused by bad configuration but by a brief mismatch between OS capabilities and policy expectations.

Logging in as a fully licensed user and then rebooting shortly after would fixed our lock screen woes.

And that’s how you spot - and explain - the Pink Elephant in the room. 🐘